Bugfixing report (posila) Stabilization goes well, the game seems to be quite stable right now (as in - not many crashes are being reported), in fact I think we are at the phase where additional bugfixing makes the game less stable, because more bugs are introduced than fixed, or some critical bug slips through our automated tests. But there are still lot of issues that need to be resolved before we declare 0.16 stable and move on to 0.17 development - the largest issue being belt compression problems. We finally fixed compatibility problem with OS X 10.9 Mavericks after it was broken in 0.15.40, when we updated our development environment to a newer version of boost, and was still broken in 0.16.x despite of us completely replacing boost with standard libraries from a newer version of C++. However, we might drop Mavericks support in 0.17, as we are considering migrating the game to OpenGL 4.1, which won’t be available on Macs that are unable to run a newer version of macOS. Speaking of OpenGL, we have several reports of the game crashing in rendering on Linux when the game is disturbed somehow (for example window resizes, loses focus or user switches workspaces), even though it is terribly inconvenient, the game seems to be otherwise playable on these configurations, and we don’t want to spend a terrible amount of time trying to figure out what is wrong with our current rendering system, when we plan to do complete overhaul of it in 0.17. We will investigate these issues, but they might go unresolved until 0.17. I’ve been looking into some corrupted saves this week, still not being able to figure out how these mysterious corruptions occur. For example this save had two iron ore entities on two different chunks saved with zero entity ID. This could have happened only if those entities had a wrong pointer to the iron ore prototype, so when the game read the ID from the prototype on saving, it would read a value from some random part of memory, or if the ID was corrupted on copying from the prototype to buffer that is saved to disk. Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?), but it would be nice to have some proof it is not some dangling pointer in our code that causes random parts of memory to be overwritten by who knows what. One way to test it would be to check for tile corruptions. Tile data for a chunk is allocated in a 4kB array at the beginning of the chunk. We could create custom allocator for chunks, so that data structure representing chunk is aligned to virtual pages. That way tile data would occupy a whole single virtual page which we could flag as read only. Then, if due to a bug we write over tile data, the OS would crash the game and we would get a stacktrace and crash dump to investigate. But if a cosmic ray would hit the RAM and flip a bit, the corrupted save would still be produced. However, we currently don’t do any custom allocation of virtual pages, so it might be quite hard to implement. We also need to change tiles sometimes (when map generation runs, when player uses concrete or landfill, when a script changes tiles, etc.) and we don’t know how expensive it would be to change pages from read only to read-write and then back to read only. So it might be just easier to spend two hours on fixing a broken save that someone sends us once every week or two.
Hello, another bugfix themed week passed and the release is here. When I'm asked to do something on friday and I say that we have the release, the typical answer is something like: "Again? Didn't you release it last week?", well we did ... :) Apart the bugfixing and moral preparation for the MP coding beast, the integration of new sounds for the 0.10 is in progress as well. First experiments of the environment sounds are done, which means that as the player goes through the factory, he can hear nearby machines working. This is very delicate matter as we don't want to make the player turn it off 5 minutes in game, but if done right, it can add a lot to the factory mood. We are very happy that people communicate on the forum, and I try to read every single post, but the last time I had marked everything read is more than 2 weeks ago. More than 5 pages of Ideas and Suggestions are waiting. The question is what exactly should we do about it, as the time spent on the forums is getting bigger and bigger every week, and I can easily "wake up" after reading it for 2 hours straight and not doing any real work on the game. We are starting to have these habits of reading in quick mode, which usually means just getting some general idea of what is going on in the thread and we usually don't read at all when we see that some other staff member replied already. So if we didn't respond to your thread, please don't take it personally, and If you feel it is important, you can bum it after some time (week at least). The big part of the work on the modding capabilities of Factorio was done during the days we were unsure about the its future. Working on something that could be used to extend the game that we were not sure anyone would play at all was looking useless. Hopefully we are still here, and new mods are arising. Some of the mods are simple but useful, like the TIme buttons, that is patching the lack of time speed configuration in-game, some are just tempting to be used because of the pictures, like Mocombat, for people that found the production chains not complex enough, there are the content-based mods like Dy tech, F-Mod and more. The growing variety of mods can only exist because modders pushed us to extend the moddability regulary and it proved more than once, that the extended interface was handy to have later even in the core Factorio, not mentioning that mods are also great incubators for new ideas that could grow into the vanilla game. So after all, we rate the time invested on modabbility to be well spent. The tesla tower from the mocombat: We are always eager to learn what you think at our forums.
Hello hello, I hope that the powerful constellation of Friday the 13th has brought you good luck or at least good humour. We have seen quite sharp decline in some Factorio related statistics in the past days so it seems that the AAA titles invasion starts to be felt ... many of you playing Fallout 4?
Hello, Bugfixing for 0.14 has been going quite well this week, and while its still in experimental we've been adding some supplementary features before programming work begins properly on 0.15. With the summer ending, things have been settling back into a nice rhythm here in the office.
Hello Factorio players, lets start our developer to player interaction right now! :)
We have a long history of trying to bring Factorio to other platforms, including consoles and mobile phones (not including April Fools). We even worked with some external companies, but the projects never even got to the point where they would run technically, let alone the complicated part of making the game playable using controllers or touch screen. After all the attempts, we even had a Friday Facts prepared that was going to say something along the lines of "we don't plan to bring Factorio to other platforms".
Hello, We had a lovely surprise waiting us this Monday, one of our fans had sent us a delicious cake: It didn't last very long... Thank you very much Conn! It certainly helped with the bug fixing push this week.
Hello, We have had quite a peaceful week here in the office. Last night we went out for a burger and a beer as a last meal with Ernestas before he flies back home for another few months. It was also quite nostalgic, as we went to a place that we used to go to frequently near our old office, and the staff still remembered us.
Hello, Today we once again dive head-first into the world of fluids.
